FIG. 1 shows a communication packet 100 based on Version 4 of the Internet Protocol (hereinafter referred to as IPv4). The packet 100 has packet parts 101-108. When considering how such packets are processed in hardware, the OPTIONS packet parts 106-107 are of particular importance as will be explained in regard to FIGS. 2 and 3.
FIG. 2 shows an example of how the packet 100 of FIG. 1 can be processed in an IPv4 environment. The process 200 comprises process steps 201-206. A dashed arrow 207 on the right-hand side of the process step 201 indicates that the process step 201 makes use of information in the packet parts 101-105 of the packet 100 of FIG. 1. Similar dashed arrows are associated with the process steps 202 and 204-206 and in each case relate to the packet parts that are required by the corresponding process step.
The first step 201 reads the header of the packet 100. The header comprises the packet parts 101-105. The step 201 checks the DESTINATION ADDRESS at 105, and calculates the header checksum. In order to determine the header checksum all the packet parts 101-105 and 106-107 are required. Accordingly, the checksum is determined over the entire header, including the options. Thereafter, a step 202 processes OPTIONS fields in the packet parts 106-107. In the present packet example 100, the OPTION relates to the IPv4 ROUTING option. The subsequent step 203 discards the packet 100 if the header checksum calculated in the step 201 is incorrect. A following step 204 performs operations concerned with fragment handling. This relates to the situation in which the packet 100 is one of a number of packets associated with a source data packet (not shown) that has been fragmented. The step 204 thus involves consideration of the PACKET IDENTIFICATION field and the FRAGMENT OFFSET field at 102 to check that fragmentation integrity has been maintained. Thereafter, a step 205 adds data from the DATA packet part 108 to a fragment buffer (not shown), provided that the check carried out in the step 204 is valid. A following step 206 establishes whether the data fragment carried in the packet 100 is the final fragment from the source data packet. If this is the case, then the data payload in the packet part 108, plus other information from the packet header is sent to the transport layer for sending to the next destination.
The process 200 can be realized using one or more processing modules implemented as state machines. It is apparent that the process 200 accesses and operates upon the packet parts 101-108 of the packet 100 in a non-linear fashion. Thus, for example, even though the packet parts 101-105 are processed in the step 201, the packet part 102 is again processed by the step 204. Because of the non-linear packet part access that is required for IPv4 processing, practical implementations of processors for IPv4 packets typically include a control module as well as other modules. The control module is generally responsible, among other things, for scheduling the flow of packet data among the other processing modules.
A multiplicity of communication paths are required for the aforementioned non-linear packet part access and processing between the control module and the other processing modules. Processing and communication also takes place between the other processing modules themselves. The arrangement of the communication paths and the data and control flows are dependent upon the type of packets being processed, and in particular, dependent upon the OPTIONS included in the packets. Thus, it is difficult to customise the structure of an IPv4 processing machine to specific circumstances.
FIG. 3 shows a representative prior art process flow for processing an IPv4 packet, using hardware processing modules in the IPv4 environment. FIG. 3 depicts an architecture having a control module 308, an IPv4 module 309, a routing module 310 and a fragmentation module 312.
In a first step 301 the control module 308 receives the packet (such as 100 in FIG. 1) from a data bus that is depicted a “B” in a circle. In a following step 302 the control module 308 sends IP header data onto the data bus “B”. The IPv4 module 309 reads the header data from the bus “B” and processes the header data in a step 313. The aforementioned steps 301-302 and 313 correspond to the step 201 in FIG. 2. In a next step 303 the control module 308 checks the OPTION field in the packet 100, and then a step 304 sends routing option data to the routing module 310 over the bus “B”. The routing module 310 processes the received routing data in a step 314. The steps 303-304 and 314 correspond to the step 202 in FIG. 2. The next step 305 again checks the OPTION field in the packet 100 after which a step 306 send fragmentation option data to the fragmentation module 312. The fragmentation module 312 processes the fragmentation data in a step 315. The steps 305-306 and 315 correspond to the steps 204-206 in FIG. 2. A re-entrant arrow 311 indicates that the processing of fragmentation data (ie adding data to the fragment buffer referred to in relation to FIG. 2) is associated with a corresponding process step for the next packet if not all fragments have yet been received. A final step 307 sends data to the transport module (not shown).
It is apparent from FIG. 3 that the packet process 300 involves repeated communication between the control module 308 and the other modules 309, 310 and 312. Furthermore, the accesses to the packet parts 101-108 of the packet 100 are non-linear.